PR types

Bug fixes

PR changes

Others

Description

Pcard-67164

一、问题描述

在CINN后端中，需要对「支持」融合的算子进行图遍历，识别并圈定为GroupOp。遍历过程是基于「图语义」的，意味着待融合的算子在「Program」层面可能相距比较远，而且它们之间夹杂着各自依赖的上游Op。因此如何选取融合后算子的「插入点」是一个非常重要的位置，若插入不恰当，极其容易引入类似编程语言中「使用未定义变量」的错误。

举个例子，如下图的「融合Group」列图中的算子E位置就是错的。

二、解决思路

由于融合Group仅发生在Block级别，因此我们只需关心Block内部的算子之间顺序是否「合法」即可，此PR中的思路包含如下定义：

• 融合算子：即图中「绿色」方框，指可被图遍历，若有连接边则可以融合成一个大GroupOp
• 上游算子：即图中「灰色」方框，指融合后Group算子的全部上游依赖算子（站在Group上，即『读入』语义）
• 下游算子，即图中「红色」方框，指融合后Group算子的全部下游依赖算子（站在Group上，即『写出』语义）

整个思路包含三个关键步骤：

1. 解析整个Group算子的上下游直接依赖的算子
2. 选取『第一个下游算子』作为『候选』插入Group算子点，在②步骤后，会将GroupOp插入此算子前面（即图中D）
3. 解析『第一个下游算子』后面所有直接和间接依赖且位置在『D之后』的的『上游算子列表』，依次插入D前面

为什么不处理『D之前』的上游算子列表？
答：从Program的Op-by-Op语义上，对于固定的算子Group，只需要保证所有『读入』的算子在前面，『写出』的算子在后面即可，故我们选择『第一个下游算子D』作为候选插入点，则『D之前』的算子顺序都是正确的，无需处理。

只调整Group算子直接依赖的上游算子是不是就可以了?
答：不可以，要递归解析上游依赖&依赖....所有算子，但限制在：

• 必须也是此Block内的
• 必须也是『D之后』的